Thanks to François Grieu for the detailed report and the work-around suggestion.
Mac OS 8.1 (even when starting up with extensions disabled) may corrupt disks created by Disk Charmer 3.1 and earlier with the Make disks larger option. Such disks work fine under System 8.0 and earlier. The problem is exacerbated by the fact that system extensions or newer versions of the Mac OS may silently create additional invisible files, potentially corrupting disks that are just inserted and then ejected.
Disk Charmer 3.1.1 and later create “larger disks” that should be safe under all known versions of the Mac OS. The work-around is explained in the technical section later in this document.
On a corrupted “larger disk”, Disk First Aid will report the disk as irrecoverably damaged:
Checking disk “1k btClpSize”.
Checking disk volume.
Checking “HFS” volume structures.
Problem: Invalid catalog PEOF, 4, 0
Test done. Problems were found, but Disk First Aid cannot repair them.
I wrote a small test program that creates empty files until a catalog expansion is triggered. So far I have found that normal HFS and HFS Plus disks are never corrupted.
Everything works fine under System 8.0, 7.6.1, and 7.1.2, even if the disk is locked and checked by Disk First Aid 8.1 under System 8.1.
Please note that using Disk Charmer is not the only way to create such disks. End users can obtain such disks in several other ways:
• using the old freeware “1433K free 0.2a” by G&S Speranza
• using the old “Disklosure” by Gabriele de Simone
• from an acquaintance, backup software or software publisher who wanted to pack more data on the disk
Technically inclined people, please read on
“Larger disks” have shortened catalogs with a custom BTree clump size. The bug occurs when the BTree clump size is 1 KByte. Adding files triggers the expansion of the Catalog BTree. The first expansion goes fine: the Catalog BTree grows from 1K to 2K by addition of a 1K segment. Following the creation of the third Catalog BTree extent, the size of the Catalog BTree field is less than the sum of the size of the first three Catalog BTree extents.
So far I did not have the patience to check if the additionally allocated blocks are reserved in the Volume Bitmap, and if these blocks are properly initialized. If not, this is bound to cause disasters later.
The Make disks larger option now uses a 1.5K BTree clump size (instead of 1K).
